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DETAILED ACTION 

Foreign Priority 

Receipt is acknowledged of papers submitted under 35 U.S.C. 1 19(a)-(d), 
which papers have been placed of record in the file. 

Objections to Drawings 

Fig. 3 shows more detail about the P2PE layer (13) and the FRM layer 
(16) that are shown in Fig. 2. The upper block of Fig. 3 corresponds to the FRM 
layer of Fig. 2, and is labeled "16". The lower block of Fig. 3 corresponds to the 
P2PE layer of Fig. 2. However, the lower block of Fig. 3 is not labeled "13" or 
"P2PE" to clarify what it is depicting. 

Appropriate correction is required. 

Objections to Specification 

Page 13, line 1 states: "As shown in Fig. 3, the P2PE layer 13 ..." 
However, there is no "13" or "P2PE" label in Fig. 3. 

Page 13, line 22 states: "With reference to Fig. 4, the frame receiver 131 
of the P2PE layer 13 ..." However, there is no frame receiver 131 in Fig. 4. This 
line should be changed to read "... the frame receiver 131 of Fig. 3 

Page 14, line 17 states: "... address determining unit 161 ..." and lines 20 
- 22 state: "The address determining unit 161 provides the results of the 
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determination to the frame processor 162." For clarity, the text should mention 
that 161 and 162 are elements of Fig. 3. 

Page 15, lines 8-9 state: "... the upstream frame processor 162', ...with 
reference to Fig. 5 ..." However, there is no element 162 in Fig. 5. Element 162 
is in Fig. 3. 

Appropriate correction is required. 

Objections to Claims 

The first line of claim 5 states: The system as in either claim 2, ..." It 
should state: 'The system of claim 2, ..." 
v Appropriate correction is required. 

Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for 
all obviousness rejections set forth in this Office action: 

A patent may not be obtained though the invention is not identically disclosed or 
described as set forth in section 102 of this title, if the differences between the subject 
matter sought to be patented and the prior art are such that the subject matter as a whole 
would have been obvious at the time the invention was made to a person having ordinary 
skill in the art to which said subject matter pertains. Patentability shall not be negatived 
by the manner in which the invention was made. 

The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1 , 
148 USPQ 459 (1966), that are applied for establishing a background for 
determining obviousness under 35 U.S.C. 103(a) are summarized as follows: 

1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating obviousness or 
nonobviousness. 
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This application currently names joint inventors. In considering 
patentability of the claims under 35 U.S.C. 103(a), the examiner presumes that 
the subject matter of the various claims was commonly owned at the time any 
inventions covered therein were made absent any evidence to the contrary. 
Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor 
and invention dates of each claim that was not commonly owned at the time a 
later invention was made in order for the examiner to consider the applicability of 
35 U.S.C. 103(c) and potential 35 U.S.C. 102(e), (f) or (g) prior art under 35 
U.S.C. 103(a). 

Claims 1, 2, 3, 4, 5, 6, and 7 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Song et al. (U.S. Patent Application Publication # 
2003/0235205) in view of RFC 3422 ("Forwarding Media Access Control 
(MAC) Frames over Multiple Access Protocol over Synchronous Optical 
Network/Synchronous Digital Hierarchy (MAPOS)") and further in view of 
Song et al. (U.S. Patent Application Publication # 2003/0190168). 

Consider claim 1, Song et al. (# 2003/0235205) clearly show and disclose 
a communication system supporting peer-to-peer communication between ONUs 
in an Ethernet-based PON, the system comprising a physical layer receiving 
frames transmitted from an OLT and data link layers including an emulation later, 
a MAC layer, a MAC control layer, and a MAC emulation layer that process 
frames received through the physical layer (Figs. 6 and 10 and page 3, 
paragraph [0036]: "Fig. 6 is a view illustrating an Ethernet PON system 
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configuration in accordance with a preferred embodiment of the present 
invention. The Ethernet PON system includes a single OLT 510 and a plurality of 
ONUs 610 connected to the OLT 510 in the form of a tree topology. The ONU 
610 includes 802.3 PHY layer 620, 802.3 MAC layer 630, a filtering function layer 
640, and a LLC layer 650."). Song et al. (# 2003/0235205) do not disclose a 
layer for generating and managing an address table that matches PON-tags of 
frames received and transmission point addresses. However, RFC 3422 clearly 
shows and discloses a network adapter with a MAPOS interface that dynamically 
generates address tables with entries from frames that it receives (Fig. 8 and 
Section 3.3.2. Dynamic setup of address table: "A NA discovers entries for its 
address table from incoming encapsulated MAPOS frames ... The timer is reset 
each time an encapsulated MAPOS frame with the same source MAC address is 
received ... If a discovered MAPOS address for a MAC address differs from the 
previously discovered address, the new one takes precedence and the address 
table entry must be overwritten."). Therefore, it would have been obvious to a 
person of ordinary skill in the art at the time the invention was made to 
incorporate the interface that dynamically generates address tables with entries 
from frames that it receives as taught by RFC 3422 in the communication system 
as in Song et al. for the purpose of having the most recent address information 
available in the address table. Song et al. (# 2003/0235205) in view of RFC 
3422 do not disclose a frame reflecting and multiplexing layer. However, Song et 
al. (# 2003/0190168) clearly show and disclose a frame reflecting and 
multiplexing layer for transmitting frames to an upstream layer or a downstream 
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layer depending on the target address of the frames (Figs. 9 and 12 and page 4, 
paragraphs [0046] and [0047]: "Upon receiving the tag Ethernet frame (Step 
421), the LLID/MUX/DEMUX layer 320 of the OLT 310 determines whether a tag 
Ethernet frame type is recorded in the Ethernet type field (Step 422). If so, the 
LLID/MUX/DEMUX layer 320 determines a corresponding port of the bridge 330 
by examining the LLID field (Step 423). The LLID/MUX/DEMUX layer 320 
thereafter deletes the Ethernet type field and the LLID field from the Ethernet 
frame, recalculates FCS (Step 424), and then transmits the resulting Ethernet 
frame to the bridge 330 through a corresponding port. After receiving the 
Ethernet frame (Step 41 1 ), the bridge 330 determines a destination address of 
the Ethernet frame and transmits the Ethernet frame to the LLID/MUX/DEMUX 
layer 320 through the particular one of the ports 331 - 335 that corresponds to 
the destination address (Step 412)."). Therefore, it would have been obvious to a 
person of ordinary skill in the art at the time the invention was made to 
incorporate the frame reflecting and multiplexing layer as taught by Song et al. (# 
2003/0190168) in the communication system as in Song et al. (# 2003/0235205) 
in view of RFC 3422 for the purpose of forwarding the frame to the correct 
destination based on the destination address. 

Consider claim 2, and as applied to claim 1 , RFC 3422 clearly shows and 
discloses a network adapter that comprises a frame receiver receiving a frame 
transmitted from the physical layer, an address table processor generating the 
address table that matches the frame address with a transmission point address, 
a frame processor transmitting the frame to an upper layer, a unit that receives a 
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frame transmitted from an upper layer and searches the address table to find the 
target address, and a processor that attaches a tag corresponding to the target 
address to a preamble of the frame. (Fig. 8 and Section 3.3.2. Dynamic setup of 
address table: "A NA discovers entries for its address table from incoming 
encapsulated MAPOS frames. The NA adds the pair {source MAC address, 
source MAPOS address} to its address table when it receives an encapsulated 
MAPOS frame. ... The timer is reset each time an encapsulated MAPOS frame 
with the same source MAC address is received. ... If a discovered MAPOS 
address for a MAC address differs from the previously discovered address, the 
new one takes precedence and the address table entry must be overwritten. ... 
In NA B2, the received MAPOS frame is decapsulated, and the MAC frame is 
forwarded to LAN N2. ... Via the Ethernet interface on NA B2, the ARP reply 
frame is received, and MAPOS encapsulation is done. ... Because the entry {hi, 
b1} is registered in the address table, b1 is determined to be the destination 
MAPOS address. The bridged frame is forwarded to the MAPOS network. 
MAPOS network delivers the bridged MAPOS frame to NA B1."). 

Consider claim 3, and as applied to claim 2, Song et al. (# 2003/0190168) 
clearly show and disclose a frame reflecting and multiplexing layer that 
comprises an address determining unit for determining a target address and an 
upstream frame processor that either forwards the frame towards an upstream 
layer or reflects the frame toward an ONU depending on the address 
determination results (Figs. 9 and 12 and page 4, paragraphs [0046] and [0047]: 
"Upon receiving the tag Ethernet frame (Step 421), the LLID/MUX/DEMUX layer 
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320 of the OLT 310 determines whether a tag Ethernet frame type is recorded in 
the Ethernet type field (Step 422). If so, the LLID/MUX/DEMUX layer 320 
determines a corresponding port of the bridge 330 by examining the LLID field 
(Step 423). The LLID/MUX/DEMUX layer 320 thereafter deletes the Ethernet 
type field and the LLID field from the Ethernet frame, recalculates FCS (Step 
424), and then transmits the resulting Ethernet frame to the bridge 330 through a 
corresponding port. After receiving the Ethernet frame (Step 41 1 ), the bridge 
330 determines a destination address of the Ethernet frame and transmits the 
Ethernet frame to the LLID/MUX/DEMUX layer 320 through the particular one of 
the ports 331 - 335 that corresponds to the destination address (Step 412)."). 
Song et al. (# 2003/0190168) do not disclose that the address determining unit 
generates and manages an address table or that the target address of a frame is 
determined based on the contents of the address table. However, RFC 3422 
clearly shows and discloses an address determining unit that generates and 
manages an address table and determines a target address of a frame based on 
the address table (Fig. 8 and RFC 3422, Section 3.3.2. Dynamic setup of 
address table: "A NA discovers entries for its address table from incoming 
encapsulated MAPOS frames. The NA adds the pair {source MAC address, 
source MAPOS address} to its address table when it receives an encapsulated 

MAPOS frame The timer is reset each time an encapsulated MAPOS frame 

with the same source MAC address is received. ... If a discovered MAPOS 
address for a MAC address differs from the previously discovered address, the 
new one takes precedence and the address table entry must be overwritten. ... 
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In NA B2, the received MAPOS frame is decapsulated, and the MAC frame is 
forwarded to LAN N2. ... Via the Ethernet interface on NA B2, the ARP reply 
frame is received, and MAPOS encapsulation is done. ... Because the entry {hi, 
b1} is registered in the address table, b1 is determined to be the destination 
MAPOS address. The bridged frame is forwarded to the MAPOS network. 
MAPOS network delivers the bridged MAPOS frame to NA B1 ."). Therefore it 
would have been obvious to a person of ordinary skill in the art at the time the 
invention was made to incorporate the address determining unit that generates 
and manages an address table as taught by RFC 3422 in the frame reflecting 
and multiplexing layer as in Song et al. (# 2003/0190168) for the purpose of 
creating an address table that contains the latest information for use in 
forwarding frames to their correct destination. 

Consider claim 4, and as applied to claim 3, Song et al. (# 2003/0190168) 
clearly show and disclose a communication system wherein the frame processor 
transmits the frame to the appropriate destination depending on its target 
address (Figs. 9 and 12 and page 4, paragraphs [0046] and [0047]: "Upon 
receiving the tag Ethernet frame (Step 421 ), the LLID/MUX/DEMUX layer 320 of 
the OLT 310 determines whether a tag Ethernet frame type is recorded in the 
Ethernet type field (Step 422). If so, the LLID/MUX/DEMUX layer 320 
determines a corresponding port of the bridge 330 by examining the LLID field 
(Step 423). The LLID/MUX/DEMUX layer 320 thereafter deletes the Ethernet 
type field and the LLID field from the Ethernet frame, recalculates FCS (Step 
424), and then transmits the resulting Ethernet frame to the bridge 330 through a 
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corresponding port. After receiving the Ethernet frame (Step 41 1 ), the bridge 
330 determines a destination address of the Ethernet frame and transmits the 
Ethernet frame to the LLID/MUX/DEMUX layer 320 through the particular one of 
the ports 331 - 335 that corresponds to the destination address (Step 412)."). 

Consider claim 5, and as applied to claim 2, RFC 3422 clearly shows and 
discloses a communication system wherein the frame reflecting and multiplexing 
(FRM) layer filters the addresses stored in the address table and only searches 
addresses that have been flagged (Section 5.4. Filtering at network adapters and 
MAPOS switches: "Network adapters should have the following frame filtering 
functions. Each NA in a VLAN is configured with the MAPOS addresses of its peer NAs 
that belongs to the same VLAN. A NA should only accept bridged MAPOS frames with 
a source MAPOS address of one of its VLAN peers. A NA should never import 
discovered address table entries with a MAPOS address that is not the address of one 
of its VLAN peers. A line interface of a MAPOS switch is made aware of the MAPOS 
addresses in the VLAN to which the interface participates. The interface discards all 
incoming bridged traffic (from the NA) that is destined to addresses outside of the 
VLAN's set."). RFC 3422 does not specifically state that target addresses will be 
flagged as part of the filtering process. However, Examiner takes Official Notice 
that it is notoriously well known in the art that a common method of filtering items 
in a table is to flag some of the items and then perform some operation, such as 
a search, only on the items that have been flagged. Therefore, it would have 
been obvious to a person of ordinary skill in the art at the time the invention was 
made to flag the addresses stored in a table and search only addresses that are 
flagged as a method of filtering the addresses, as in RFC 3422, in the 
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communication system as in Song et al. in view of RFC 3422 and further in view 
of Song et aL for the purpose of reducing the amount of time spent searching for 
addresses in the address table. 

Consider claim 6, and as applied to claim 5, RFC 3422 clearly shows and 
discloses a communication system wherein the processor attaches a 
broadcasting tag to a preamble of a frame in the case where the target address 
of the frame is not in the address table, and transmits the broadcasting tag to the 
physical layer (Section 3.1 . Destination MAPOS address for forwarding a MAC 
unicast frame: "In NA, entries of the form {destination MAC address, destination 
MAPOS address} are held in its address table. When a MAC frame is received 
by the Ethernet interface, the address table is searched using the destination 
MAC address as the key. ... If no matching entry exists, MAC broadcast 
forwarding (3.2) is used."). 

Consider claim 7, and as applied to claim 1, Song et al. (# 2003/0190168) 
clearly show and disclose a communication system wherein the frame reflecting 
and multiplexing (FRM) layer performs a multiplexing function between frames 
from an upstream layer and frames that are reflected in the frame reflecting and 
multiplexing (FRM) layer (Figs. 8 and 10 and page 3, paragraph [0039]: "The 
LLID MUX/DEMUX layer 350 checks an Ethernet type field of an Ethernet frame 
received from the OLT 310. If the Ethernet type field indicates a tag Ethernet 
frame, the LLID MUX/DEMUX layer 350 checks an LLID field and transmits the 
Ethernet frame to the LLC layer 360 only if the LLID is identical to its own LLID, 
and discards the other frames whose LLIDs are not identical to its own LLID. 
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During upstream transmission to the OLT 310, the LLID MUX/DEMUX layer 350 
inserts, into the existing Ethernet frame, an Ethernet type field in which a tag 
Ethernet type is recorded and an LLID field in which its own LLID is recorded, to 
thereby convert the existing Ethernet frame into the tag Ethernet frame."). 

Claim 8, 9, 10 and 11 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Song et al. (U.S. Patent Application Publication # 
2003/0190168) in view of RFC 3422 ("Forwarding Media Access Control 
(MAC) Frames over Multiple Access Protocol over Synchronous Optical 
Network/Synchronous Digital Hierarchy (MAPOS)"). 

Consider claim 8, Song et al. clearly show and disclose a communication 
method for a system supporting peer-to-peer communication between ONUs in 
an Ethernet-based PON, the method comprising receiving a first frame from the 
ONUs and forwarding to an upper layer or reflecting to an ONU the first frame 
based on results of the address determination (Figs. 9 and 12 and page 4, 
paragraphs [0046] and [0047]: "Upon receiving the tag Ethernet frame (Step 
421 ), the LLID/MUX/DEMUX layer 320 of the OLT 310 determines whether a tag 
Ethernet frame type is recorded in the Ethernet type field (Step 422). If so, the 
LLID/MUX/DEMUX layer 320 determines a corresponding port of the bridge 330 
by examining the LLID field (Step 423). The LLID/MUX/DEMUX layer 320 
thereafter deletes the Ethernet type field and the LLID field from the Ethernet 
frame, recalculates FCS (Step 424), and then transmits the resulting Ethernet 
frame to the bridge 330 through a corresponding port. After receiving the 
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Ethernet frame (Step 41 1), the bridge 330 determines a destination address of 
the Ethernet frame and transmits the Ethernet frame to the LLID/MUX/DEMUX 
layer 320 through the particular one of the ports 331 - 335 that corresponds to 
the destination address (Step 412)."). Song et al. do not disclose generating an 
address table that matches a tag of the first frame and a transmission point 
address, managing the address table, and determining a target address of the 
frame based on the address table. However, RFC 3422 clearly shows and 
discloses generating an address table, managing the address table, and 
determining a target address of the frame based on the address table (Fig. 8 and 
Section 3.3.2. Dynamic setup of address table: "A NA discovers entries for its 
address table from incoming encapsulated MAPOS frames. The NA adds the 
pair {source MAC address, source MAPOS address} to its address table when it 
receives an encapsulated MAPOS frame. ... The timer is reset each time an 
encapsulated MAPOS frame with the same source MAC address is received. ... 
If a discovered MAPOS address for a MAC address differs from the previously 
discovered address, the new one takes precedence and the address table entry 
must be overwritten. ... In NA B2, the received MAPOS frame is decapsulated, 
and the MAC frame is forwarded to LAN N2. ... Via the Ethernet interface on NA 
B2, the ARP reply frame is received, and MAPOS encapsulation is done. ... 
Because the entry {hi , b1} is registered in the address table, b1 is determined to 
be the destination MAPOS address. The bridged frame is forwarded to the 
MAPOS network. MAPOS network delivers the bridged MAPOS frame to NA 
B1 ."). Therefore, it would have been obvious to a person of ordinary skill in the 
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art at the time the invention was made to incorporate generating an address 
table, managing the address table, and determining a target address of the frame 
based on the address table as taught by RFC 3422 in the communication method 
as in Song et al. for the purpose of creating and managing an address table to 
use in forwarding frames to the correct destination. 

Consider claim 9, and as applied to claim 8, RFC 3422 clearly shows and 
discloses a communication method that comprises receiving a frame transmitted 
from an upper layer and searching the address table to find the target address, 
and attaching a tag corresponding to the target address to a preamble of the 
frame, and transmitting the tag to a physical layer (Fig. 8 and Section 3.3.2. 
Dynamic setup of address table: "A NA discovers entries for its address table 
from incoming encapsulated MAPOS frames. The NA adds the pair {source 
MAC address, source MAPOS address} to its address table when it receives an 
encapsulated MAPOS frame. ... The timer is reset each time an encapsulated 
MAPOS frame with the same source MAC address is received. ... If a discovered 
MAPOS address for a MAC address differs from the previously discovered 
address, the new one takes precedence and the address table entry must be 
overwritten. ... In NA B2, the received MAPOS frame is decapsulated, and the 
MAC frame is forwarded to LAN N2. ... Via the Ethernet interface on NA B2, the 
ARP reply frame is received, and MAPOS encapsulation is done. ... Because the 
entry {hi , b1} is registered in the address table, b1 is determined to be the 
destination MAPOS address. The bridged frame is forwarded to the MAPOS 
network. MAPOS network delivers the bridged MAPOS frame to NA B1 ."). 
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Consider claim 10, and as applied to claim 8, Song et al. clearly show and 
disclose a communication method wherein the frame is transmitted to the 
appropriate destination depending on its target address (Figs. 9 and 12 and page 
* 4, paragraphs [0046] and [0047]: "Upon receiving the tag Ethernet frame (Step 
421 ), the LLID/MUX/DEMUX layer 320 of the OLT 310 determines whether a tag 
Ethernet frame type is recorded in the Ethernet type field (Step 422). If so, the 
LLID/MUX/DEMUX layer 320 determines a corresponding port of the bridge 330 
by examining the LLID field (Step 423). The LLID/MUX/DEMUX layer 320 
thereafter deletes the Ethernet type field and the LLID field from the Ethernet 
frame, recalculates FCS (Step 424), and then transmits the resulting Ethernet 
frame to the bridge 330 through a corresponding port. After receiving the 
Ethernet frame (Step 41 1 ), the bridge 330 determines a destination address of 
the Ethernet frame and transmits the Ethernet frame to the LLID/MUX/DEMUX 
layer 320 through the particular one of the ports 331 - 335 that corresponds to 
the destination address (Step 412)."). 

Consider claim 11, and as applied to claim 9, RFC 3422 clearly shows 
and discloses a communication method wherein the frame reflecting and 
multiplexing (FRM) layer filters the addresses stored in the address table and 
only searches addresses that have been flagged (Section 5.4. Filtering at 
network adapters and MAPOS switches: "Network adapters should have the 
following frame filtering functions. Each NA in a VLAN is configured with the MAPOS 
addresses of its peer NAs that belongs to the same VLAN. A NA should only accept 
bridged MAPOS frames with a source MAPOS address of one of its VLAN peers. A NA 
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should never import discovered address table entries with a MAPOS address that is not 
the address of one of its VLAN peers. A line interface of a MAPOS switch is made 
aware of the MAPOS addresses in the VLAN to which the interface participates. The 
interface discards all incoming bridged traffic (from the NA) that is destined to addresses 
outside of the VLAN's set."). RFC 3422 does not specifically state that target 
addresses will be flagged as part of the filtering process. However, Examiner 
takes Official Notice that it is notoriously well known in the art that a common 
method of filtering items in a table is to flag some of the items and then perform 
some operation, such as a search, only on the items that have been flagged. 
Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time the invention was made to flag the addresses stored in a table and 
search only addresses that are flagged as a method of filtering the addresses, as 
in RFC 3422, in the communication system as in Song et al. for the purpose of 
reducing the amount of time spent searching for addresses in the address table. 

Conclusion 

Any response to this Office Action should be faxed to (571) 273-8300 or 
mailed to: 

Commissioner for Patents 

P.O. Box 1450 
Alexandria, VA 22313-1450 

Hand-delivered responses should be brought to: 

Customer Service Window 
Randolph Building 
401 Dulany Street 
Alexandria, VA.22314 
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Any inquiry concerning this communication or earlier communications from 
the 

Examiner should be directed to Leah Richmond whose telephone number is 
(571) 270-1774. The Examiner can normally be reached on Monday-Thursday 
from 9:00am to 6:00pm Eastern Standard Time. 

If attempts to reach the Examiner by telephone are unsuccessful, the 
Examiner's supervisor, Rafael Perez-Gutierrez can be reached at (571) 272- 
7915. The fax phone number for the organization where this application or 
proceeding is assigned is (571) 273-8300. 

Information regarding the status of an application may be obtained from 
the Patent Application Information Retrieval (PAIR) system. Status information 
for published applications may be obtained from either Private PAIR or Public 
PAIR. Status information for unpublished applications is available through Private 
PAIR only. For more information about the PAIR system, see http://pair- 
direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free) 
or 703-305-3028. 

Any inquiry of a general nature or relating to the status of this application 
or proceeding should be directed to the receptionist/customer service whose 
telephone number is (571 ) 272-2600. 

Leah Richmond 
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